Distributed in an Automatically Switched Optical Network (ASON) architecture defined in ITU-T G.8080 are control-plane node equipment each containing a Route Controller (RC) component providing a connection controller with route information for connection inside a domain of responsibility. Such route information is end-to-end, or may be based on next-hop. In addition, to achieve network management, the RC can also respond to topology requesting information.
With development of a Multi-Protocol Label Switching (MPLS)/Generalized Multi-Protocol Label Switching (GMPLS) network, network topology becomes increasingly complicated with enormous amount of routes, and path computation becomes increasingly complicated as well. Meanwhile, traffic projecting requires a network equipment to perform route computation under complicated constraints. such complicated computation often requires a lot of CPU computing resources and memory resources, impacting hardware performance of the network equipment and stability of the entire network to some extent.
Accordingly, IETF PCE workgroup proposes an MPLS/GMPLS network structure based on a Path Computation Element (PCE). In such a structure, based on known network topology and a known constraint, a PCE, as a functional entity dedicated to path computation in a management domain, computes an optimal path meeting the constraint according to a request of a Path Computation Client (PCC). A PCE may be located anywhere in the network, for example by being integrated in a network equipment such as a Label Switch Route (LSR) or an Operating System (OS), or may be a separate equipment. Communication between a PCC and a PCE as well as between a PCE and a PCE is performed via a PCE Communication Protocol (PCEP).
RFC 5440 describes in particular a PCEP architecture including a transport layer adopting a TCP, a transport port 4189, with 7 PCEP message type defined. RFC 5440 specifies that what must be accomplished at an initial stage of establishing communication between a PCC and a PCE are: 1) establishment of a TCP connection between the PCC and the PCE via three handshakes; and 2) establishment of a PCEP session based on the TCP connection. RFC 5440 specifies two constraints that: 1) at any time, any pair of PCEP communicating ends can have only one PCEP session; 2) at any time, there can be only one TCP connection between any pair of PCEP communicating ends.
However, in multi-PCE collaboration, including intra-domain collaborative computation by multiple PCEs, inter-domain collaborative computation by multiple PCEs, and collaborative computation by parent and offspring PCEs in a hierarchic PCE architecture, a PCE will serve as a TCP server in monitoring at a port 4189 a message sent by a PCC, and also will serve as a TCP client in actively seeking connection to another PCE for PCEP message exchange. An implementing mechanism among such PCEs in collaborative computation has to be formulated to meet the two constraints.